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A System and Method to Develop Health-care Information Systems 

by 

Pradeep Achan 



Field of the Invention 



The present invention in the field of information technology has extensive 
applications in the health care domain and provides a framework for development of 
innovative health care information management systems. . 



Background of the Invention 



Delivery of life-critical health care requires timely access to mission-critical health care 
information. Health care delivery institutions the world over, whether in the public or 
private sectors, are faced with an uphill battle of ensuring people are protected by timely 
access to high quality health care at an affordable price. 

Even sophisticated health care institutions in the advanced nations are plagued by lack of 
timely access to patient-records and related knowledge base, which are up to date and 
consistent across all domains such as clinical, biographic, financial etc. Empowered by a 
facility to accurately record and retrieve information on patient-care, medical personnel 
would be motivated to guarantee that a patient is receiving the best available treatment at 
a reasonable price. In addition to hygienically clean environment and life-style, a 
patient's welfare depends on availability of adequate supply of safe prescriptions, having 
minimal side effects. 

Frequently, by a review of patient's information from the different sources referred to, 
diagnostic/therapeutic procedures prescribed by the medical team are often questionable 
or inappropriate, for the reasons noted hereunder: 

• Imprecise - usually doctor's notes are hand-written or scribbled. Nurses and 
pharmacists are very likely to misread the physician's instructions and are 
prone to take incorrect follow-up actions. 

• Contrasting - two or more physicians attending on a patient often 
independently prescribe medication for the same patient. If they fail to consult 
with each other, or when a patient's records are not available for timely 
reference by medical personnel before specifying the next course of treatment, 
this results in potentially life-threatening side effects. Even an alert nurse or 
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pharmacist hardly ever catches such errors in a timely fashion. 



• Ill-timed - Some prescribed tests/procedures frequently need to be scheduled 
at the proper time and carried out in a specific order. Problems are often 
reported when the tests are not well coordinated. As a minimum, two items 
need to be addressed: (1) record of the required tests and procedures to be 
performed and their schedule and, (2) a list of equipment and services along 
with their availability. When the vital elements of information are in different 
and/or incompatible information systems, matching these lists to prescribe an 
appropriate treatment program is very difficult. It is conceivable that a patient 
could be scheduled for a test when the appropriate gear or medical personnel 
with relevant expertise are unavailable, leading to disastrous results depending 
on the severity of the patient's medical condition. 



Currently available health care information management systems are severely 
inadequate in their ability to inter-operate amongst different functional entities. Albeit 
individually they may have been fine-tuned for optimal performance, these information 
systems are incapable of harmoniously interacting with each other. There are islands of 
information-blocks with minimal communication among each other. Thus for instance, 
integrating the Patient Records database with the hospital's Financial department is a 
tedious exercise, needing several manual steps to retrieve/process the electronically 
stored records* Often the same data gets stored in different systems. This leads to the 
problem of data getting updated in one system, but not in the other, causing data 
inconsistency. For example, if the Human Resources Employee system is not adequately 
integrated with the Health-care Information System, the staff data concerning access 
privileges may be stored separately in the two systems. As a security leak, even former 
employees colud log-in and retrieve confidential patient data, if the user accounts were 
de-activated in one system but not in the other... The main rationale for this drawback is 
that currently there is no extensible and customizable information system that fosters 
development of health care information systems which support inter-operability among 
diverse standards-compliant modules. 

Legacy health care information management systems have limited incorporation of 
security in terms of data integrity and long-term data retention. Re-engineering of 
medical information systems is quite a challenging notion for organizations in the health 
care industry, due to technical complexities as well as the general reluctance to change. 
Other observed deficiencies include challenges of scalability and redundancy, with the 
growth in the sheer volume of data of the order of millions of records handled by larger 
health care organizations. 
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Problem of building extensible health care applications 

There have been many approaches to develop standards pertaining to various domains of 
health care arena like DICOM in image communication and HL7 in health care data 
communication. Both of them define standards for communication between 
heterogeneous health care applications. But their efforts for the definition and 
development of a middleware operating system that could serve as a platform to meet the 
relevant industry standards and ease the building of an enterprise-class health care 
information systems have been inadequate. 

On a different note, CORBA Med from Healthcare Domain Task Force (HDTF) of the 
Object Management Group (OMG) defines a set of object-level standards (by defining 
standard interfaces). While distributed objects form an effective means to achieve 
interoperability, this does not fully address the problem of developing an enterprise level 
health care application conforming to the global standards. CORBA Med defines a 
standard for component-based architecture but fails to provide a ready-to-use platform 
and also makes the task of writing CORBA Med compliant components, quite tedious. 
Another neutral platform framework for building health care information systems is the 
Riche frame work from Group Riche overlaid on top by the DHE (Distributed Health- 
care Environment) . The Riche framework and DHE are too general and provide set of 
tightly coupled components, rendering the framework highly domain-centric. 

A unique observation of the health care information systems across the globe is the 
diversity found in the workflow of health care institutions compared to other domains 
like BFSI (Banking, 

Finance, Security and Insurance). Existing applications need approximately ten times 
more work than the original effort s expended for tailoring it to meet the needs of global 
clients,. A simple example depicting this scenario is the introduction of a mandatory 
Financial Clearance before admitting a patient or. ordering of patient-services. Only a 
workflow oriented, rule-based middleware that is configurable at the higher level [i.e. 
Application layer] can address these issues. 

Compared to the pace with which new technologies are being introduced minimal 
efforts are being devoted to link and use these technologies in the health care arena. This 
phenomena can be illustrated by use of the wireless technology in hospital information 
systems. Although the innovatiove wireless industry is booming with newer 
applicationsfor the health care industry , very little 

standards are defined . The options available are often not viable in terms of their cost 
effectiveness and incompatibility to interface with existing 

frameworks. Similar is the case with Telemedicine that has immense potential but seen 
minimal field deployment due to lack of open standards and supporting frameworks. 
Vendors should 

be able to design applications for health care industry based on an open, extensible 
framework similar to the development of applications for the Windows or Linux OS 
platforms. 
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A major drawback of the current HIS scenario is the use of individual ERP 
packages for many of the indispensable components of health care information systems 
like the inventory, payroll and human resources management. A tiered approach with a 
domain-neutral lower tier and domain-specific upper tier, together supporting 
applications at the highest tier can be a solution to the problem. For example, all the 
modules of the higher tier can use the services of a rule based flow control system 
defined in the lower tier. 



What is clearly needed is a methodology/framework to build healthcare software 
applications that are well-integrated with each other, that provides accurate and 
dependable updated health care information in real-time, while being resilient to changes 
in business and legal requirements, adaptable and extensible with organizational needs, 
and provides disaster recovery. Also needed, is a system to make this possible with 
relative ease. 



Summary of the Invention 

In a preferred embodiment a system and method for development of health care 
information systems is provided. A system for development of healthcare information 
systems comprising of a server with a middleware operating system stratified into 
multiple tiers composed of software components. Software components in one tier 
interact only with those in the adjacent tier. The higher tiers provide Application 
Programming Interfaces (API) for development of software specific to healthcare 
information applications, while the lower tiers provide functions of storage, 
monitoring, communication, security, management, data back-up, and recovery of 
health care information. 

In this health care middleware operating system (HMOS), the first or the lowest tier, 
namely the Foundations tier, interfaces with standard platforms such as J2EE and 
.NET and provides core operating system functions of resource allocation, process 
scheduling, memory management including caching, data storage, back-up and 
recovery, and communication services. It also includes Workflow Engine and Rules 
Engine. The second tieris the Domain Services tier, which interfaces with the 
Foundations tier, which are populated with co-operative software components to 
guarantee Quality of Service (QoS) requirements of security, privacy, latency and 
reliability utilizing the Foundations tier and provides services including Clinical 
Data Retrieval, Clinical Data Acquisition, further providing API and domain- 
specific customizable rules-engines for development of application software for 
health care information systems. 

The Foundations Tier [FT] of HMOS comprises of: 

• Authentication and Authorization 

• Monitoring 
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• Messaging 

• Auditing 

• Scheduling 

• Resource allocation 

• Knowledge Integration 

• Image Sound & Video Management 

• Back-up and Disaster Recovery Services 

The Domain Services Tier [DST] of HMOS provides APIs that are customizable and 
compliant with standards. The APIs provide for development of health care 
applications comprising of: 

• Drug Interaction Information store with APIs to access and operate on the 
stored information 

• Terminology services for interpretation of health care related terminology 

• Workflow Services 

• Rules engine for specifying portions of behaviors of health care applications 

• Natural Language Processing module for natural language understanding and 
translation between multiple natural languages 

• Notification module for communication between modules in the DST tier 

• Compliance software module for Digital Imaging and Communications 
(DICOM) standard, 

• Compliance software module for Health Insurance Portability and 
Accountability Act (HIPAA) standard, 

• Compliance software module for International Statistical Classification of 
Diseases and Related Health Problems (ICD), 

• Compliance software module for Health Level Seven (HL7) ANSI standard, 

• Compliance module for SNOMED multi-disciplinary standard vocabulary 
designed by clinicians, 

• Report management service using CPT codes 

• Module for Clinical Data Documentation System (CDS) for capturing and 
retrieving medical diagnosis details of a patient 

• Patient Care Management 

• Patient Identity Management (PIM) 

• Imaging Modality Management and Picture Archiving and Communication 
system 

• Security management 

• Inventory and order management service 

In the preferred configuration of HMOS, the method of developing health care 
applications to guarantee Quality of Service (QoS) requirements of security, privacy, , 
and reliability comprises of the following steps: 

• using a library of object-oriented programming classes to create new data 
objects 
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• using a library of object-oriented methods to create an application to 
operate on the data objects created 

• automatically verify that the application created is compliant with 
standards and that it satisfies QoS requirements. 

In the preferred embodiment , a method for communication among various software 
components comprises of steps based on publish-subscribe model as follows: 

Every software component publishes its availability of data and services. A 
subscription manager keeps a record of which software components would like to 
subscribe to sets of data and services at any time at any time, if a software 
component requires or publishes data or services events are triggered for the data 
and service exchange to be executed. A permanent destination is set up for all 
outgoing messages, the response destination could be associated with an 
automatic persistent store, and therefore all outgoing messages could be sent 
persistently with guaranteed message delivery. 

In the preferred embodiment , a method of scheduling tasks committed to by various 
modules ensures that every temporal and resource constraints is satisfied thus 
providing QoS guarantees. 

In the preferred embodiment , a system for providing security for health care 
information called Globally Controlled Locally Managed system as part of the 
domain services tier comprises of the logical division of the security control called 
Security Domain and the Security Domain Administrator (SDA) wherein the 
application will be globally controlled by one administrator and he/she will be 
creating and assigning privileges to SDA and the SDA locally manages the users 
under their Security Domain. 

The API at higher tiers is designed to make sure that any health care application 
developed using the API is compliant with health care protocols namely HL7, 
DICOM, HIPAA, ICD, CPT for seamless integration of multiple disparate health care 
information systems developed using the HMOS. A system part of the domain tier for 
capturing the entire medical diagnosis details of a patient and the system includes the 
different steps for capturing the clinical as well as the diagnostic, research 
information on a patient. 

In the preferred embodiment, in the higher application tier, using the API provided by 
domain services tier are a set of software application modules that provide 

• automated mechanisms for admission, discharge, and transfer of patients. 

• purchase order creation and communication for both materials and drugs. 

• Electronic Medical Records Management Module (EMR). 

• Patient Care Management Module (PCMS). 

• authentication and authorization using smartcards and biometric devices. 
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• side effects of drugs, interactions among drugs, and interactions among 
drugs and food interfaces with the database in Foundations tier through the 
domain services tier 

• telemedicine for remote medical diagnosis and treatment with integrated 
video conferencing. 



Brief Description of the Drawing Figures 



Figure. 1 is the high-level architecture of the Health-care Middleware Operating System 
(HMOS) that describes the various tiers. 

Figure 2: depicts how HMOS supports applications and platforms. 

Figure 3 : Security Architecture of HMOS 

Figure. 4: Scheduling Diahram of HMOS 

Figure. 5 : Terminology Services 

Figure. 6: Clinical Documentation Frameworks 

Figure. 7 : Clinical Data Acquisition. 

Figure. 8 :shows an outline of the Globally Controlled Locally Managed (GCLM) 
Security System 

Figure. 9 depicts the Elements and Composition of GCLM module. 

Figure 10 : Publish/Subscribe Model 

Figure 1 1 : Patient Admission Flow Chart 

Figure 12 : Workflow based Patient Admission Process in HMOS 

Figure 13 : IP Billing Workflow 

Figure. 14 : HMOS Purchase Management System Architecture 
Figure. 15 : Concept of Purchase Item. 
Figure. 16 : Patient Care Management 
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Description of the Preferred Embodiments 



Introduction 

An operating system is a system that manages resources within a computing machine. 
Executions of applications on a computing machine are coordinated and managed by the 
operating system. Operating systems functions include process scheduling and resource 
allocation. Middleware is a system that provides a uniform interface for applications to be 
developed for execution on multiple and disparate computer-programming platforms. 
Quality of Service (QoS) is often used to define a level of performance of a computing 
and communication system. Typical performance parameters are latency and througput. 

The present invention called Health care Middleware Operating System (HMOS) is a 
middleware with operating system functionalities designed to provide a substratum to 
develop health care information systems applications, which are customizable and 
reconfigurable. In the present invention we extend the typical notion of QoS to include 
security, privacy, latency, satisfaction of real-time constraints, and high-availability and 
provide guaranties to satisfy QoS requirements imposed by healthcare applications 
developed using HMOS. A preferred embodiment is shown in Figure 1. 



Health-care Middleware Operating System (HMOS) 

Health care Middleware Operating System (HMOS) (Fig :2 .227)is a middleware 
operating system designed to provide a substratum to develop health care information 
systems applications, which are customizable and reconfigurable. 



HMOS is comprised of 3 tiers: 

• Foundation Services Tier (FST) ) (Fig : 1 . 157)comprises of modules with 
operating system functionalities such as resource allocation and scheduling, and 
module with middleware functionalities such as messaging and knowledge 
integration. FST interacts directly with an underlying programming platform 
including generic enterprise-class frameworks including J2EE, .Net, and 
healthcare specific frameworks such as Mumps. 

• Domain Services Tier (DST) (Fig : 1 . 100)comprises of modules with middleware 
functionalities such as patient care and identity management, compliance with 
healthcare standards, and security management. DST provides Application 
Programming Interfaces (API) for developing healthcare applications. 

• Application Services Tier (AST) (Fig :2 .200)comprises of applications developed 
using APIs provided by DST will be known. 
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DST provides Application Programming Interfaces (API) for development of 
application software for healthcare information systems while the CST provides functions 
of storing, monitoring, communication, securing, management, backup, and recovery of 
healthcare information that guarantees Quality of Service (QoS) requirements of security, 
privacy, latency, satisfaction of real-time constraints, and high-availability. 

An execution of a healthcare application at AST involves invocation of one or 
more modules in DST using the APIs provided by DST. The invocation of the DST 
modules may result in the invocation of one or modules in FST. Modules in FST may 
execute using functions and methods provided by the underlying programming platform. 
The resulting data from the execution of the respective modules in FST will be 
transmitted to the respective modules in DST, which in turn are transmitted to the 
corresponding healthcare application. 

Foundation Service Tier (FST) 

Major Operating System (OS) functionalities like memory management, 
scheduling, resource allocation and middleware functionalities such as object caching, 
messaging and object relational mapping belongs to Foundation Service Tier. The entire 
data store of all applications is associated with this Tier. 

FST tier is comprised of the following functional modules. 

• Authentication and Authorization 

• Monitoring 

• Messaging 

• Auditing 

• Scheduling 

• Resource allocation 

• Knowledge Integration 

• Image Sound & Video Management 

• Back-up and Disaster Recovery Services 

Authentication and Authorization 

The Authentication sub-system has been developed to comply with all levels in the 
security hierarchy and features of typical state-of-the-art health care information systems. 
Authentication through smart card and biometric devices is also supported in the HMOS 
design. 

The Foundation Services tier of the HMOS system provides a set of loosely coupled, 
API's that can be used independent of the underlying development platform. This 
interface tier enables domain services to authenticate and enforce access privileges upon 
HMOS-users. It has been implemented on a standard Pluggable Authentication Module 
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framework (PAM). Public or Private-key based security mechanisms can be deployed 
within the Authentication sub-system. Pervasive HMOS system additionally supports 
Authentication through wireless and mobile computing devices. 

Authentication and Authorization API's facilitate HMOS' Domain Service Tier to 
provide role-based, identity-based or privilege-based, highly customizable and 
configurable user-interfaces conforming to standard Security protocols. 



Messaging 

Messaging is used in HMOS for communication between health care applications 
or modules. Subscription manager controls the Messaging Domain of HMOS. This 
architecture proposes that a permanent destination is to be set up for all out going 
messages, the response destination could be associated with an automatic persistent store. 
So all outgoing messages could be sent persistently with guaranteed message delivery. 

The activities performed in the application tier are published and managed by an 
entity called Subscription Manager where all the active users can subscribe the published 
messages. For example, as soon as a patient completes the registration, the ADT sub 
system of the Application Tier can publish that information so that the relevant 
Specialty/Doctor can prepare for the patient's arrival. Another example will be that of 
publishing the event of drug prescription so that the pharmacy people can keep the drugs 
ready before the patient's arrival. 

Monitoring 

FST tier's Monitoring Interface provides a re-definable scheme to effectively monitor 
resources of an HMOS system with a sophisticated notification rule set. The Monitoring 
module is user-configurable to schedule and set priorities for monitoring activities. 
Working in conjunction with Messaging interface, the Monitoring interface supports a 
real-time monitoring and messaging framework to detect and report alarms in the event 
of system failures. The events monitored are also user-configurable, so that HMOS also 
has the capability to deliver an effective and intelligent alarm management scheme. The 
domains monitored by the HMOS alarm management sub-system include user-access, 
performance, data & network availability. 

Monitoring module using algorithms from the AI discipline is capable of learning from 
an event's experience and sends advance messages, in anticipation of the event's 
outcome. This facilitates a highly scalable and extensible design, supporting a wide range 
of open software and hardware platforms. In a plug-and-play fashion plug-in of any new 
software or hardware, can be automatically detected by the Monitoring interface. 
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Auditing 

The Auditing Interface sub-system empowers HMOS to monitor and log any/all changes 
in data and service settings in an untarnished manner. The interface contains a set of 
configurable APIs that can define the level of auditing needed for different areas of the 
HMOS system. The Auditing interface is tightly coupled with the Security features of 
HMOS. Administration, monitoring, maintenance and storage of the logging activity are 
carried out in a restricted and secure environment. The Auditing module is endowed with 
built-in intelligence to determine the severity of all changes and raise appropriate alarms 
by collaborating and communicating with the HMOS Messaging service. 

An important and distinctive feature of HMOS is that for all transactions processed by the 
Auditing module, snap-shots of pre-change data and post-change data, along with the 
delta of change is saved. Furthermore, information elements pertinent to the data- 
changes, i.e. who (user name) - when (time) - where (IP Address - Station Name) 
information are also saved for data archives. 

Knowledge Integration 

Knowledge Integration is a unique feature of HMOS concerned with the 
processing and management of information from diverse multiple sources in an open, yet 
secure environment . Knowledge Integration specializes in the provision of multiple- 
source information delivery solutions, and the individual components that make a diverse 
range of information sources visible in an open, yet secure, environment. This 
environment is set up using HMOS Connector Architecture (HCA). Here data and 
functional knowledge are extended through this knowledge based connector architecture 
that provides a means to represent as XML entities and functional knowledge as set of 
APIs. These entities get triggered, based on rule-based trigger points. All the external 
resources are pluggable to the HMOS only through this architecture. This leads to an 
easier and faster cycle for the development of scalable, secure, and transactional 
enterprise applications that require connectivity with multiple Information Systems. HCA 
has a structured connection pool such that it creates connections in an efficient manner 
and does not cause resource starvation. XML binding provides simple and platform 
independent means for the polydentate feature of HMOS. 

Image, Sound and Video Management 

HMOS provides standard interfaces for management of image, sound and video 
information. Along with clinical data these are managed just as text data, to provide an 
Integrated Clinical Data (ICD). HMOS furnishes a set of APIs associated with Visual and 
Sound functionality. The resultant adaptability enables HMOS application to manage the 
clinical document along with related information from image and sound domains. HMOS 
incorporates all standard archiving solutions for medical, scientific, and microscopy 
applications. This provides for HMOS-users to systematically develop database - a 
warehouse of intelligent clinical data that can be useful for any research or 
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review/analytical studies. The strategic importance of this system should be clear - it 
enables creation of a true, paperless patient record. 

APIs encapsulate all the functionalities for saving, querying and retrieving data from the 
image, sound and video resources. The recorded sound can be converted into 
corresponding text using a built-in voice recognition tool... The APIs, furnish an added 
advantage to HMOS-users, to transform captured video images into frames, for archival. 
This can be extremely useful for Medical Transcription services. Image archival into a 
PACS system can be accomplished in various formats such as DICOM, JPEG, GIF, and 
TIFF. . The APIs, for converting captured video images into frames and archiving it in 
any format, are an added advantage provided by HMOS in medical arena. 

Data Back-up and Recovery Services (DBRS) 

The DBRS ensures safety of data associated with HMOS. This 
system coming as an integral part of HMOS FST tier and it makes HMOS to face any 
type of disastrous situations related to data loss. Centralized control and administration is 
its main feature. It aims mainly on restoring the system in a bare minimum time even in 
the case of complete data loss, and to retain the system in its pure original transactional 
state with little user level interaction. For restoring procedure to work smoothly it uses a 
two stage backup procedure, one recurring in a daily basis and the other happens 
incrementally, according to the wish of database administrator. The backup taken 
incrementally even ensures the life of latest transactional data just before crash. As it 
implements a log based back up and recovery procedure we can relay it for even table 
level data loss. Thus the hierarchy of recovery ranges from the entire database to a single 
table. The daily back up procedure also provides provision for integration with OLAP 
and other Knowledge Integration Systems, which makes them synchronized with latest 
data. It also provides option for routine database checking for improved data integrity and 
security. 

Another important feature of DBRS is that it can be accessed through web-based 
interface, which allows DBA to monitor and control (only necessary and limited control) 
the various status of backup procedure even from a remote. This is implemented under 
tight security realm so that no leak outs will happen any way under any circumstances. It 
also provides the facility to take back-up on portable devices like tape drives to ensure 
the security of data even due to natural calamities. This also provides reports to DBA in 
daily basis and even sends necessary acknowledgments through E Mail. Its also 
provides statistical data regarding the database such as size and various other information 
regarding results of the routine checking and updating. 

The entire disaster recovery procedures are automated so that the latency time of 
recovery is reduced to the most possible extent. The backups are moved to remote 
locations and various copies are maintained at various geographical locations for further 
safety. The entire distributed storage of the backups and its fast retrieval during a 
recovery process is the main feature of DBRS. It automatically checks for the most recent 
versions of backups and recent transactional data to get a smarter snap shot. The various 
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information about checkpoints at various time stamp levels is maintained to get the most 
recent updates in the database. 

Scheduler 



The HMOS scheduler (Fig :4 :326)is an integral part of the FST. Scheduling is 
concerned with the allocation of limited resources to tasks so as to optimize certain 
functions. It schedules all the tasks in the HMOS based on the various scheduling 
algorithms. These scheduling algorithms works on the basis of attributes specified in the 
configuration files of the Domain Service Tier. This feature enables the top-level services 
to schedule clinical tasks according to the local situation. The scheduler itself schedules 
all the core services and these tasks are not visible to the outer tiers. Other tasks that can 
be scheduled according to the entry in the configuration files in the DST and these entries 
can be modified on the basis of requirements. Also new tasks can be entered in the same 
file. The attributes in the file are name of the service, date, time and status. Applications 
can dynamically change the date time parameters specified there. This feature facilitates 
the applications to schedule and configure their jobs as they wish. 

Apart from core service scheduling in a clinical environment scheduling of 
services and procedures in a proper way is essential for better patient care. So HMOS 
provides a fruitful and effective algorithm for each schedulable task. 

In the area where scheduling tasks get much complex, like OT scheduling, HMOS 
uses algorithms that are evolved as a result of detailed research and in the mean time 
these algorithms strictly follows all medical standards. 

Operation theatre activities such as pre-anesthetic check-ups, pre-anesthetic notes 
generation, recording anesthesia details, maintaining the list of procedures for various 
operations, recording operation details, and maintaining operation theatre availability, are 
important while scheduling the Operation Theatre. Basically some of the parameters for 
the above activities are depend on place and situation. So essentially for the smooth going 
of the work the system must have a facility to adapt with change. HMOS provides these 
features. I.e. as said earlier the scheduler of FST works according to the parameters 
specified in the Domain service Tier. 

Scheduler Maintaining Quality Of Service 

The scheduler also guarantees that every resource constraints are satisfied. Thus 
providing Quality Of Service for all the tasks that are to be scheduled. Each task is 
associated with a number of constraints and the scheduler notifies the task initiator in 
such a way that if the constraints cannot be satisfied within the current context, it will 
generate a precise indication of the reasons thereof, providing QoS guarantees. This can 
also be explained in terms of security measures taken by each individual module in the 
HMOS. Since quality of service is a set of methods and processes a service-based 
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organization implements to maintain a specific level of quality. Also the notification of 
the scheduler to the task initiator is a classic example of maintaining QoS as key feature 
of the entire system. 

Resource Allocator 

The resource allocation is one of the most important features of an operating 
system. HMOS provides a uniform flexible interface that helps to allocate various 
resources required by DST services. Examples of resources are service processing time, 
queue buffer sizes, and high-level object resources. The HMOS utilizes resource 
allocation to satisfy QoS requirements. In HMOS, the resource allocator supports the 
allocation of multiple heterogeneous resources like beds, materials, drugs, operation 
theaters, doctors, and nurses. When the resources are no longer required, the allocated 
resources are released and will be available for reuse. 

Domain Service Tier (DST) 

The Domain Service Tier (DST) (Fig : 1 . 100)hides the lower level complexities of 
the Foundation Service Tier from the Applications Services Tier(s) (AST) (Fig :2 
.200). The DST provides APIs to develop health care information systems applications. 

The DST comprises of the following software modules: 

• Drug Interaction Information store with APIs to access and operate on the 
stored information 

• Terminology services for interpretation of health care related terminology 

• Workflow Services 

• Rules engine for specifying portions of behaviors of health care applications 

• Natural Language Processing module for natural language understanding and 
translation between multiple natural languages 

• Notification module for communication between modules in the DST tier 

• Compliance software module for Digital Imaging and Communications 
(DICOM) standard, 

• Compliance software module for Health Insurance Portability and 
Accountability Act (HIPAA) standard, 

• Compliance software module for International Statistical Classification of 
Diseases and Related Health Problems (ICD), 

• Compliance software module for Health Level Seven (HL7) ANSI standard, 

• Compliance module for SNOMED multi-disciplinary standard vocabulary 
designed by clinicians, 

• Report management service using CPT codes 

• Module for Clinical Data Documentation System (CDS) for capturing and 
retrieving medical diagnosis details of a patient 

• Patient Care Management 

• Patient Identity Management (PIM) 
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• Imaging Modality Management and Picture Archiving and Communication 
system 

• Security management 

• Inventory and order management service 



Drug Interaction Information Store 

The Drug Interaction Information database will give instant access to information 
about the adverse reactions for most of the drugs. This also includes the information 
about drug-to-drug interaction. The classification also includes various categorizations 
based on patients' age such as geriatric, as well as the clinical areas under which the drug 
is widely accepted. It also provides information about preventable drug reactions and the 
available information about clinical trials for each drug. The clinical research data 
regarding the food-drug interaction is another indispensable part of this tier. This part 
provides research reports regarding the analysis of chemical structures of drugs and its 
metabolic pathways with the help of bioinformatics analysis. Thus this part provides 
various information regarding biochemical reactions and the inferences that can be used 
in further researches. 

Terminology Services 



Instead of setting each repository for the CPT (Fig 5.350, SNOMED (Fig 5.353 
)and ICD (Fig 5.356) the HMOS handles these DSL services using its Terminology 
services module. The Terminology service provides the repository for all the clinical 
standards. This includes a Mapping Service that helps to map the terminologies of 
different standards, so that any application built on top of HMOS can communicate to the 
inner services using any of these standards. Since the terminology services works as a 
base or all the clinical terminologies, the DSL is able to accommodate any newer 
standards without affecting the core structure. This type of architecture makes HMOS 
viable to integrate different systems using different standards. 



Workflow Module 

Business process in healthcare enterprises are modeled as state-machines undergoing 
various state changes within HMOS. HMOS provides a Workflow Engine in DST that 
allows to define new business processes and link them with existing business processes. 
Each business process is split into different steps, called process states. Triggers that alter 
the state of the process are called events. Events may arise from within HMOS, through 
user interaction or from an external system. Change of state from one state to another is 
referred to as state transitions. Workflow Engine in DST provides an XML-based 
configuration mechanism to define process states, events and state transitions. 
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Any business process within applications in AST of HMOS can be modeled using the 
services extended by the Workflow Engine. Example of a business process can be 
scheduling admission for a patient for a performing a surgery. Admission scheduling 
involves doctor's order for admission, getting available date of the surgeon, getting 
financial clearance from the insurance company, getting receipt of necessary tools and 
instruments for the surgery etc. Events can include doctor changing the date of his 
availability, a special consumable item needed for the surgery not being available in stock 
etc. These events can alter the outcome of the business process. These events and 
transitions can be coded in the HMOS workflow configuration files. With the changes in 
the configuration, admission scheduling application in AST gets dynamically configured 
to reflect the new configuration. 

Rules Engine 

Rules provide a method of dynamically changing the characteristics and behavior of 
applications developed using the APIs provided by DST. Thus rules can be modified, 
added, and deleted on the fly while the health care application is running. Rules are 
stored in a rule base, and the rules engine ensures that the set of rules are consistent with 
each other, that there is no contradiction between any two rules. 

The syntax of the rules is as follows: 

{Patterns to be matched} "->" <Actions to be taken> 

The pattern to be matched on the left hand side may consist of regular expressions. The 
action to be taken contains software program data and method invocations. Thus when an 
application in AST or a module within DST requires to consult the rules engine, the 
module or applications send a pattern of data in question and the rules engine invokes the 
action to be taken in the form of software program method invocations if the pattern 
matches any of the rules in the rules base. Thus, applications can be customized or 
reconfigured while they are still executing to the extent that the rules engine allows based 
on the rule base. 

Modules for compliance with Health-care Standards 

Compliance with health care information standards is imperative for interoperability and 
acceptance by health care industry. The DST comprises of software modules that 
implement health care industry and federal standards such as HL7, DICOM, ASTM, 
ICD, SNOMED, CPT, and HIPAA. Each of these modules provides APIs for 
development of health care applications in AST. Therefore any application developed 
using the appropriate API is ensured to comply with that specific standard. SNOMED 
Clinical Terms is a multidisciplinary electronic vocabulary designed by clinicians for 
clinicians. In HMOS each medical term has a SNOMED basis. This feature is 
crosschecked in the Domain Service Tier so as to keep the Clinical integrity of the data. 

The integrity, security and privacy of the clinical data are handled using a set of 
HIPAA compliant rules. The HIPAA based rules are designed to protect the privacy, 
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authenticate, authorize, and maintain integrity. These are necessary to protect against the 
threats of eavesdropping, manipulation, impersonation and unauthorized access to health 
care information of individuals. 



Imaging Modality Management 

The Imaging Modality Management capability is achieved through a set of a DICOM 
APIs in the Domain Service Tier. An application at AST uses APIs provided by the 
Imaging Modality Management module to query and retrieve images from remote 
radiology imaging modalities using DIMSE (DICOM Message Exchange) protocol. 
Furthermore, it provides Picture Archiving and Communication System (PACS) facility 
for application at the AST. 

Clinical Data Documentation 

The Clinical Documentation System captures all the medical diagnosis details of a 
patient (like, Primary diagnosis reports, Service Order reports, Operation Notes from 
Operation Theatre, Other patient care reports, Discharge summaries etc.) in a structured 
and advanced way as the patient walks through the various nodes of the workflow of the 
hospital. The Clinical Documentation System is represented as in the Figure 8. 

The Clinical Documentation system uses two separate workflows for Data 
capturing and Data retrieval. The Data capturing details includes various methodologies 
to acquire the widely spread patient's clinical data, either electronically or by manually. 
By manual ways the data can be input through clinical templates, and saved to the clinical 
data store. Also by electronically it can be gathered by setting the properties of the 
controls of clinical template such a way that it automatically pop-up clinical data 
previously entered. The Data Capturing System of the above is shown in figure 6 . 

The above said clinical data is captured in this Advanced Clinical Documentation System 
in many ways. 

1 . Through user defined clinical templates. By template we mean data entry 
forms. Each template has many numbers of data entry control boxes with 
properties like text justification, left and right indenting etc. There are 
many numbers of controls, which will accept specific type of the clinical 
data in different formats, like Combo boxes, Rich edit boxes, Text areas 
etc. The added advantage of such templates is that the users of the Clinical 
documentation system can freely design the varies clinical data that has to 
be collected though this templates. The user can add/modify/delete 
controls from a template arrange their position and change their properties, 
as he/she likes. The users also can edit the header and footer of the 
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template and they can arrange the printable format of the saved 
documents. 

2. The Image annotation control is an important tool available in this 
Advance Clinical Documentation System, which will allow the users to 
upload specific images of the patient like, X- ray images, CT images or 
Endoscopy images and annotate on those images with required clinical 
data. The added advantage of these image annotation controls is that the 
user can incorporate them in data a capturing template, which is discussed 
above. 

3. The ICD (Fig :7 471) (International Statistical Classification of Diseases 
and Related Health Problems, RIO) and CPT (Fig :7 474) (Clinical 
Terminology and Procedural coding system) coding systems are 
implemented as controls in the above said Clinical Documentation system. 
The advantage is that the user will get the ICD and the CPT coding 
conventions as single controls, which can be incorporate in the data 
capturing templates as per the requirements. Also they can retrieve the 
clinical data based on the ICD and CPT codes in later times. 

4. Audio recording and replaying facility is another advantage of the said 
Advanced Clinical Documentation System. The doctors and/or in-charge 
medical personal can input the diagnosis and other reports through a 
microphone, which will save as an audio file in the Integrated Clinical 
Data Store, and that can be replayed for dictation and/or medical 
transcription in the later time. The audio replaying system is very 
advanced, which includes the facility to Pause, Replay etc. 

Whenever a new template is created or a template is modified, it will ready for 
use in the system. 

The Clinical Documentation System allows the user to capture clinical data from 
different direction of the workflow, such as, Primary diagnosis details of a patient can be 
collected from the doctor's room, and/or the operative notes can be collected directly 
from the operation theatre itself and so on. This means the system is flexible and scalable 
for any hospital's workflow. The collected clinical information of the patient is stored in 
the Clinical database in a normalized and structured format. 

The security policy of the Clinical Documentation System restricts the insertion, 
modification and deletion of the clinical data from the Clinical Documentation System 
Archive. The authorized users (Security Domain Administrators) can define a security 
policy for the end user inserting and accessing the clinical data through the given 
interface of the Advanced Clinical Documentation System. The system supports: service 
center level, template level, and field level security policy to the end user those how are 
entering the clinical information. There is provision to define security policy for 
authorized access of Internet for sending the clinical information in the Clinical 
Documentation Archive as E-Mails and also for sending it as Fax. The integrity of the 
archived clinical data is kept to the higher priority through the basic security policies 
defined in this system. 
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Reports Management Module 

From Clinical Documentation Archive, clinical information is retrieved and 
reports generated by the reports management module in different formats as follow: 

1 . As printable reports: The printable reports of the clinical data of a 
patient can be taken for any purpose like giving to the patient and/or 
sending it to other physicians. The printing of such reports can be 
restricted by define such a security policy. 

2. Informative and research oriented reports: The cumulative reports and 
research oriented reports suffices to access a wide range of the clinical 
data saved in the data store. The accession of clinical data can be 
restricted using the security policy. The authorized user can have an 
advanced searching facility in the clinical database for specific type of 
reports they would like to have. 

Graphical representation: The graphical reports can be viewed satisfying a condition of 
the user, is important for research purposes. The authorized users can take such reports of 
many kinds like Pie charts, Bar diagrams, Line diagrams etc. for representing the data. 

Patient Identity Management 

The Patient Identity Management System generates a unique identifier, which is used 
to identify a patient. An Identifier is a unique way of naming. A social security number, a 
patient number, and an email address can all be considered Identifiers because they 
uniquely identify a person. Similarly, a hospital's address, and registration number can be 
Identifiers for that institution because they can be traced back to that particular hospital. 
In middleware, Identifiers can be used to assign names in this manner, including abstract 
concepts such as software applications or entities like security levels. The entity named 
by an Identifier is known as its subject. 

The HMOS patient identifier uniquely identifies the patient across any 
geographical barriers. The format is alphanumeric and the three major portions of the 
identifier are, 

1 . A unique geographical code 

2. A unique Hospital Code 

3. Local Patient Identification Number. 

This feature becomes even more essential for telemedicine applications because it 
helps the system to distinguish the patients across the geographical barriers. 
Security Management 

Security subsystem of HMOS includes Authentication and Authorization module (Fig 1: 
160) FST; Security Management module ((Fig :1.148))of the DST and security 
administration applications that are built in AST using the DST APIs. Authentication and 
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Authorization module of the FST also works closely in conjunction with Configuration 
module, Auditing module and Messaging module of FST. Security Management module 
of DST uses the services of the above-mentioned FST modules and works closely with 
other modules of the DST, most important of them being Workflow Engine, Rule 
Engine, Patient Identity Management and HIPAA module. Authentication and 
Authorization module in FST can interact with lower-level platform provided 
authentication and authorization mechanisms such as Lighwight Directory Access 
Protocol (LDAP) and Pluggable Authentication Module (PAM) module, and custom- 
made security databases. 

HMOS is designed with security management of large health-care enterprises with 
multiple sites in mind. For this, HMOS provides a security authorization assignment and 
management method called the GCLM (Globally Controlled Locally Managed) security 
management. Design goal of GCLM provides for the necessary scalability and 
management ease for large healthcare enterprises. Structure, functionality and 
effectiveness of GCLM security management method is explained below. 

In GCLM, the lowest granular unit of security right is called a 'privilege'. Application 
designers, with the help of domain experts, define the 'privileges'. Privileges can be 
action-level, field-level or object-level. Permission to use a particular menu item, perform 
a particular action in the HMOS system, view a report or initiate a workflow process are 
examples of action-level privileges. Privilege to view or modify a field in a user interface, 
see a particular column in a report are called field-level privileges. Privilege to view a 
particular instance of a business object (for a example, a purchase order with a currency 
value exceeding 10,000, a bill of amount 200 etc.) is called object-level privilege. 

Lowest granular person or business process to which security is assigned (security 
assignee) is called a 'user'in HMOS. For a particular installation of HMOS, one user can 
be specified a HMOS System Administrator (HSA). (Fig 8:503) HSA divides the entire 
user base into one or more non-overlapping Security Domains and assigns users into 
these Security Domains. HSA can specify an administrative authority, Security Domain 
Administrator (SDA) (Fig :8 505), for each Security Domain. SDA inherits his or her 
rights from the HAS through explicit assignment. 

All the managed assignments within each security domain may further be audited, 
restricted or controlled by the HSA. 

Each SDA in her own right can further subdivide the security domain into smaller 
domains. This provides for a hierarchical organization of security domains. SDA in turn 
will act as the global controller for the newly created some domains within his or her 
domain and gets the full controlling authority over the new sub-security domains. 

A special characteristic to note is, that even though a SDA has total security management 
control over all the users under his or her security domain, he or she is not limited to 
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granting such rights to a user belonging to a different domain. This provision provides 
the flexibility that is needed in large enterprises where functional privileges are not 
always hierarchically granted. A user may be serving cross-domain tasks for the 
organization. Each of such cross-domain security grants are treated as special audit points 
by the HMOS and are thus regularly audited by the HAS. 



Privileges are named to reflect the application units that they are protecting. They are also 
attached with a severity level. For example, Billing-Alter_line_item-Medium refer to a 
privilege for altering a bill's line-item in 'Billing' application module with a severity 
rating of 'medium'. Privileges are created and managed solely by the Application 
Designer. The names of Privileges are unique across all HMOS installation. 

Privileges are grouped into 4 Application Roles' (also called Privilege groups). In 
contrHAT to privileges, Application Roles are created to correspond to a business 
operation or a group of related business operations. The names of 'Application Roles' are 
unique only within an installation of HMOS, and has no meaning beyond the boundary of 
a single installation. The process of naming is always done by the HS A in consultation 
with all SDA ! s. The precise Seperation of Concerns of a 'system meaning' of privileges 
and 'domain meaning' of application roles and the corresponding naming process and 
scheme is very suited for large enterprise security management. 

SDA's can further group the Application Roles into Business Roles. Business Roles are 
the lowest assignment units to end-users of the system. Business Roles are made unique 
by the HMOS within each security domain and thus SDA can group the application roles 
to suit the domain needs unique to his or her domain and thus he was she is left free to 
create his own her on schemes of privilege administration. SDA f s can also do cross- 
domain assignments. For example a pharmacy billing personnel in a 'pharmacy' may 
organizationally belong to 'finance' security domain, while can functionally be assigned 
a 'Browse Drugs List' application roles by Pharmacy SDA. Cross-domain assignments 
are, even though locally administered, are closely audited and can be restricted or fully 
prevented globally by HSA. 

Any application in the AST of the HMOS should publish its securable resources. Lowest 
granular unit of items to be protected is called a 'Resource'. Resources can include 
'actions' (which are logical operations or transactions performed by HMOS), fields 
(which are components in a user interface form) and objects (which are business objects 
or a group of business objects). Correspondingly HMOS offers action-level, field-level, 
object-level privileges. 
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THE PUBLISH - SUBSCRIBE MODEL OF COMMUNICATION 

The Messaging Module of the Foundation Services is composed of 
an entity called Subscription Manager. The Messaging component uses the publish - 
subscribe model of communication. This forms the base of the platform-neutral nature of 
HMOS by which applications are isolated from environmental differences. The 
components of the subscription manager and its interaction with other HMOS 
components are depicted in Figure 4. As shown in the figure, Subscription Manager 
(Fig 10.603) is made up of a Message Publisher (Fig 10.604), Message Manager (Fig 
10.605) and a Message Queue (Fig 10.606)The Message Publisher is responsible for 
publishing the messages. Whenever a request for publishing a new message comes, the 
Message Publisher gets invoked. The Message Manager keeps track of the lifecycle of 
the messages and Meta information about the messages. The Message Queue is a 
priority-based queue of messages, which are yet to be subscribed. The priority of a 
message can be changed dynamically. The figure also shows a Message Store (Fig 
10.609) This is 

where all the messages are persisted for guaranteed message delivery. Figure 10:600 
represents the HMOS Application Services Tier, Figure 10:602 the Domain Services 
Tier. Figure 10: 607 shows the Active Subscribers, which can be any HMOS component. 

Communication among various components of HMOS is achieved through the Publish - 
Subscribe Model in which components does not exchange events directly. Instead they 
directly or indirectly use the services of the Subscription Manager. The Subscription 
Manager propagates the event in the form of messages. Messaging can occur between 
components within a particular tier or across the tiers. It is also possible to target the 
message to components of a particular tier. 

Almost all the components of HMOS directly or indirectly use the services 
of the Subscription Manager. Consider the example of the ADT module of the HIS, 
which belongs to the Application Tier of HMOS (Fig 10.600)starting a workflow for the 
admission of the patient. The ADT module may use one or more than one components of 
the Domain Service Tier (Fig 10.601).The task of raising a notification about admission 
request lies with the Workflow component of FST tier (. For the accomplishment of the 
task the Workflow component will in turn use the services of the Subscription Manager. 
A message is published across all active subscribers (Fig 10.607) from which the right 
subscriber responds to the message and initiates actions for completing the task. 
Subscription is achieved through the declaration of the components about the events in 
which it is interested. The publisher may or may not have to know about the identity of 
the subscriber. Likewise the subscriber need or need not be aware of the existence of the 
publisher. Message delivery is guaranteed in the sense that a permanent destination is set 
up for all outgoing messages and the response destination could be associated with an 
automatic persistent store. This message storage component is shown as Figure 4.6. 



23 



Also, the delivery of the message is in real time fashion so that if a message does not get 
subscribed within a time limit the system will raise a failure message to the appropriate 
component. Because the data can be sent from the publisher to the subscriber as soon as it 
becomes available, publish-subscribe architectures provide low latency delivery. This is 
very much needed since certain messages can be life critical. The same reason is applied 
for prioritizing the messages in the Message Queue (Fig 10.606) 



It is very costly to construct publications without prior knowledge of what 
subscribers are actually interested in. The subscription manager has a learning component 
by which it keeps track of the delivery of a message from a publisher. This helps in faster 
delivery of messages. The publisher also has the facility to specify criteria so that the 
messages are only delivered to the subscriber who matches the criteria. But in general, 
the flow of information from publishers to subscribers is determined by the specific 
interests of the subscribers rather than by any explicit subscriber criteria assigned by the 
publisher. With this communication pattern, subscribers subscribe to information with 
the subscription manager that is of interest to them without regard to any specific source, 
while publishers simply publish information without addressing it to any specific 
destination. The Subscription Manager is responsible for interpreting subscriptions and 
delivering the relevant publications to subscribers. 

The Publish - Subscribe Model reduces the hardships of application 
development since the information does not need to be read or pulled; it is just made 
available simplifying tremendously the programming of communication in automation of 
tasks. Development of software modules for modality management can make use of this 
paradigm. For example, to read the data delivered by a particular modality it is only 
needed to create a subscriber for the particular event. Since events are simply a special 
form of message, HMOS explicitly support the development of event-oriented distributed 
applications ranging from user interfaces to server components. 

Consider the real world scenario within a health care organization where a 
patient is ready for discharge as per the patient care management sub system (PCMS). 
Now this Information is published by PCMS through the Publish Manager component. 
The Billing Sub System component of HIS has an active subscription with the 
Subscription Manager and identifies the message as a trigger and acts accordingly. 



Application Service Tier 

The following software modules resident within the HAL tier, enable it to carry out some 
of its prime responsibilities {such as, assuring user-transparent access, seamless 
integration with HMOS proprietary and third-party software packages}: 

q Health Care Information System (HIS) 

This software application in turn serves as the primary interface to the users in 
ADT, Billing and Ordercom domains as noted below. 



24 



o ADT Automated mechanisms for admission, 

discharge, and transfer of patients 

o Procurement Module Purchase order creation and communication 

for both materials and drugs. 

o Electronic Medical Records Management Module (EMRS). 
o Patient Care Management Module (PCMS). 

o Authentication and authorization using smart cards and biometric devices. 

o Side effects of drugs, Interactions among drugs, and Interactions between drug 

and food interfaces with the database in Foundations Tier through the Domain 

Services Tier 

o Telemedicine for remote medical diagnosis and treatment with integrated video 
conferencing 

o ERP Systems Electronic Resource Package 

o HR System Human Resources System 

o Third-Party EMRs Third-Party Electronic Medical Records 

o Finance Systems 



Admission, Discharge and Transfer 

The software application module namely ADT which is part of the HIS of the 
Application tier using the API provided by Domain Services Tier includes the Admission 
of patients to the hospital, Transfer of patients between different kinds of rooms 
depending upon the procedures or services that has to be performed for the patient and 
Discharge of the patients from the hospital. 

The entire admission process can be considered as a set of smaller workflows and the 
process transaction manager should make sure that the integrity among the sub 
workflows are maintained The major admission workflow involves the sub workflows 
such as admission request from the out patient department, Financial agreements or 
counseling known as FIC, cash clearance/advance clearance known as admission 
clearance etc. The ADT module is accommodated with the facilities to request for a bed 
for the patient from any department or from the doctors assistant, getting the bed status of 
the entire hospital where by allocating appropriate bed to the patients and ordering drugs 
and other services to the patients from the corresponding nursing station or ward. The 
workflow environment provided along with the HMOS comprehensively advocates the 
request sending, bed allocation and the service ordering methods enabling the real time 
processing of each admission request and ordering requests. Those who are precisely 
authorized can pull out the details of the admitted patient at the different centers easily at 
any instance of time. The HMOS also has the ability to have the same function 
distributed among different centers where different functions are getting processed. The 
drug orders, other service orders, bed transfer requests and all related functions are 
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integrated and the different instances of the functions are uniquely and accurately 
distributed. 

The bed transfer for the patient is initiated when the concerned doctor is suggesting for 
some procedures (surgery for e.g.), which should be preformed in a different room or 
bed. The information about the room, the kind of bed, hours or days that the patient is 
allocating a particular kind of bed are matters very much under consideration and the HIS 
is furnished itself with a unique way by which the details of the bed transfers that the 
patient undergone are taken care off. 

The discharge process mainly includes preparation of the final bill for the patients, which 
includes the calculation of bed charges and service charges. The bed charges are 
calculated based on the duration that the patient was allocated with a particular kind of 
bed. Once all orders are finished processing the final bill can be generated automatically 
against the orders and patient can be discharged once they clear their liabilities. The 
patient will also be given a Discharge Summary containing the results of all the 
diagnostics, procedures, medications and investigations done during his stay in the 
hospital. 

Example Scenario Patient Admission Process 

1: Legacy Systems 

One of the most common and important process in any health care information 
system is the patient admission process. Patients who requires full time attention by a 
trained physician, those who are directed by the doctors to undergo certain procedures or 
services for some dates, and those who are going to undergo certain surgeries etc. has be 
admitted in the hospital. Whenever the doctor suggested that the patient has to admit for 
certain procedures, the actual admission process starts. 

In the available legacy systems the capability of transferring concurrent 
knowledge across the different set of users is not that effective. So the process flow 
becomes very slow and tiresome. When the data is distributed across the network the 
transfer would still be slower and the data may not be the real time data. 

The entire admission process can be considered as a set of smaller workflows and 
the process transaction manager should make sure that the integrity among the sub 
workflows are maintained. In the legacy systems it is cumbersome to maintain the list of 
complicated workflows, which will result in the slower velocity services to the patients. 

The major admission workflow involves the sub workflows such as admission 
request from the out patient department, Financial agreements or counseling known as 
FIC, cash clearance/advance clearance known as admission clearance etc. All these will 
take time when we consider the fact that no real time information flow is happening. The 
patient or someone with the patient has to go to all different counters, sit and wait for 
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hours and still they are not getting the necessary service that they want. These scenarios 
enlighten the thought to have workflow based messaging services across different sub 
processes. The HMOS is working on top of the above-mentioned concept, which is found 
to suits to the requirements as well as for the fully automated and timely processing of the 
services. 

The fact that the legacy systems can not supply real time information in a 
distributed domain is overcome by the suitable supply of the messaging services across 
the domain. As the functional areas keep on increasing the distributed, domain specific 
data migration become too complex that the legacy system can't afford the performance 
degradation at the transactional areas. In a widely distributed domain like a health care 
middleware operating system the number of transaction as well as the criticality of the 
transactions will be higher to many other known domain and legacy systems find it 
difficult to manage these extremely difficult and complicated functionalities. 

HMOS handles the complex domain specific information in an effective way. It 
has a message driven data transfer mechanism using which the user are supplied with the 
real time information whenever any change in any part of the data is affected and also 
he/she is the right user to review the change. Consider the case when the patient is 
coming for an admission. As soon as the patient is registered the user interface task list of 
the user who should know what to do next will be updated with the information that the 
patient has got registered and he/she will be coming to meet the doctor at any time. This 
information is vital as the concerned user can allocate a time slice of the doctor for that 
patient also and when the patient is coming there is no need of waiting for getting the 
doctor consultation as the every formalities of the consultation is already over as the user 
is provided with the information at the earliest time that one could imagine. 

The user at the particular department will make an admission request as and when 
the doctor is suggested for admitting the patient for doing some procedure(s). The same 
admission request will pop up at the FIC administrators screen as a task item and all 
he/she has to do is give FIC clearance to the patient after having counseling. Since the 
states are related, after FIC clearance a message is published to the Admission such that a 
patient is ready for admission and the admission clerk can complete his/her task list as 
soon as possible. There is no case that the patient is waiting for getting the FIC clearance 
as a message is published for every state change. Hence the task list of the user is getting 
updated on every step so that the user will have a thorough Domain knowledge. Finally 
the duty of the staff reduces to, simply clearing their task list. 

This kind of message driven service management across the users are the primary 
objective of the workflow implementation. This also explains how the workflow based, 
message driven, process and functional management helps in the faster distribution of 
domain specific information in a vast functional area like a hospital environment. 

Purchase Management 
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Purchase Management Module (PMS) of HIS provides comprehensive coverage of the 
procurement functionality. PMS manages issuance of Purchase Orders (PO) for both 
disposable materials and drugs. The PMS Module, linked in close coordination with the 
Inventory and Financing modules, automates all aspects of an ordering process. 



Purchase Item 

Incorporation of the concept of a 'Purchase Item' by the PMS provides embellishments to 
the user- friendly aspects of HMOS based applications. Identified by designated part # a 
Purchase Item refers to an individual item within a PO. Purchase Item is central to 
creation of both a PO and Goods Received Note (GRN) in the PMS. Graphical definition 
of the Purchase Item' is illustrated below. 



For every purchased item, is likely that multiple vendors can supply the same item. 
Furthermore, depending on the manufacturer, same vendor may have multiple catalog 
items that could alternately be used as equivalent to the item description. The 'Vendor- 
Manufacturer-Catalog Number' combination determines the uniqueness of a Purchase 
Item. A preferred vendor is one having the highest (pre-assigned) rating for each 
purchase item. The purchase item concept helps HMOS-users to select the most preferred 
vendor for each item to be procured before issuance of the PO. 

Purchase Order Creation 

The processes involved in the creation of a PO for both disposable material and drugs are 
similar. An approved Purchase Requisition (PRQ) shall exist prior to creation of the PO, 
which is then sent to the Purchase Manger for approval. Once the PO is approved, it is 
ready for release to the vendor/supplier. In case of any modifications to a PO, PMS will 
ensure that, only pre-authorized users can make any amendment. On receipt of the items 
against a specific PO, Goods Received Note (GRN) will be prepared. Stock updates 
within Inventory Management are performed only on confirmation of the Goods 
Received Note. 

Automatic Conversion of Unit of Measure 

PMS is endowed with a feature of automatic conversion of the vendor's standard units of 
measure to the hospital-standard unit of measure (UOM). 

Purchase Order Reduction 

This module has the ability to consolidate multiple purchase requests into a single PO. 
This provides a means to augment the procurement activity, by reducing the number of 
POs that need to be managed. 

Partial order receiving 

Partially delivered quantities - in a PO are managed by reducing the quantity in the 
purchase order. Un-delivered items can be identified as Tending' and the purchase order 
status will be held pending until complete delivery of all items. 
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Tracking Vendor and Manufacturer Performance 

Purchase Management sub-system provides APIs to obtain comprehensive data on a 
vendor or manufacturer's performance. Offering different views of vendor and 
manufacturer activities also exposes multiple View Helper classes. For example, when 
multiple vendors supply the same purchase item, HMOS can provide statistical summary 
[tabular, graphical representation of data] of the item quantities supplied by each vendor 
over different time periods. 



Electronic Medical Record Management Module 

The increasing demand for well-structured and accessible patient data, in combination 
with developments in computer science, sparked a great interest in the development of an 
electronic patient record. HMOS worked on this direction and comes with a set of APIs 
for developing a comprehensive, confidential, interoperable, accessible, accountable, 
flexible Electronic Medical Record System in which data exchange will be according to 
public health care standards. And such systems will be able to accept data (historical, 
radiological, laboratory, etc) from multiple sources including physician's offices, hospital 
computer systems, laboratories, and patients' personal computers 

Public standards 

Many current systems fragment medical records by using incompatible means of 
acquiring, processing, storing, and communicating data. These incompatibilities may 
result from a failure to recognize the need for interoperability or they may be deliberate, 
with the aim of locking consumers into using a particular system. Either way, the practice 
precludes sharing of data across different applications and institutions. 

A notable feature of EMR module is instead of proprietary methods it uses open 
standards. At minimum, open standards allows exchange of information among different 
systems. 

For example, HL7 (Health Level Seven) is a voluntary consensus standard for electronic 
data exchange in health care environments. It defines standard message formats for 
sending or receiving data on patient admissions, registration, discharge, or transfer; 
queries; orders; results; clinical observations; and billing. HMOS by using an open 
messaging standard such as HL7 allows different health applications, such as a laboratory 
system and a record system, to "talk" to each other. 

Other standards have been adopted by HMOS for various other data exchanges: DICOM 
defines messages for encoding and exchanging medical images. Programs that exchange 
data according to open standards may nevertheless store and use those data internally in 
proprietary ways. 
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Comprehensiveness 

Because care is normally provided to a patient by different doctors, nurses, pharmacists, 
and ancillary providers, and, with the passage of time, by different institutions in different 
geographical areas, each provider must be able to know what others are currently doing 
and what has previously been done. Outpatient records should contain, at least, problem 
lists, procedures, allergies, medications, immunizations, history of visits, family medical 
history, test results, doctors 1 and nursing notes, referral and discharge summaries, patient- 
provider communications, and patient directives. The records must also span a lifetime, 
so that a patient's medical and treatment history is available as a baseline and for 
retrospective analysis. 

Accessibility 

Medical records may be needed on a predictable basis (as at a scheduled doctor's visit) or 
on the spur of the moment (as in an emergency). They may be needed at a patient's usual 
place of care or far from home. They may be needed when the patient can consent to their 
use or when he or she is unconscious and only personal or societal policy can dictate use. 
Ideally, the records would be with the patient at all times, but alternatively they should be 
universally available, such as on the World Wide Web. In addition, with patients' 
permission, these records should be accessible to and usable by researchers and public 
health authorities. 

Interoperability 

Different computerized medical systems should be able to share records: they should be 
able to accept data (historical, radiological, laboratory, etc) from multiple sources, 
including doctors 1 offices, hospital computer systems, laboratories, and patients' personal 
computers. Without interoperability, even electronic medical records will remain 
fragmented. For different systems to share data effectively HMOS uses a common set of 
communication protocols and message formats and allow the import and export of all 
their data. By using common data structures and open source programming HMOS 
fosters the possibility of effective data exchange among systems. 



Privacy and Confidentiality 

For most patients, the appropriate degree of confidentiality will fall in between and will 
be a compromise between privacy and the desire to receive informed help from medical 
practitioners. Because an individual may have different preferences about different 
aspects of his or her medical history, access to various parts of the record should be 
authorized independently. For example, psychiatric notes may deserve closer protection 
than immunization history. Further, patients should be able to grant different access rights 
to different providers, based either on their role or on the particular individual. Most 
patients will probably also choose to provide a confidentiality "override" policy that 
would allow an authenticated health care provider in an emergency to gain access to 
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records that he or she would not normally be able to, though at the cost of triggering an 
automatic audit. The EMR system that can build on HMOS can use the security and 
authorization features of HMOS, which can be easily integrated with it. 

Accountability 

Any access to or modification of a patient's record should be recorded and visible to the 
patient. Thus, data and judgments entered into the record must be identifiable by their 
source. Patients should be able to annotate and challenge interpretations in their records, 
though we believe they should not be able to delete or alter information entered by others. 
Patients should also be able to see who has accessed any parts of their record, under what 
circumstances, and for what purpose. Reliable authentication feature of HMOS is 
essential to make this feasible. Appropriate laws can reinforce accountability built into 
the records system. 

Flexibility 

Patients should be able to grant or deny study access to selected personal medical data. 
This can be based on personal policies or decisions about specific studies. An example 
policy might say that any study may use data if they will be stored only in aggregated, 
non-identifiable form. Whether patients are willing to be solicited on the basis of 
characteristics of their record should also be controllable. Patients could provide time 
limited keys to other parties to access a specified segment of their record. For example, 
they could permit hospitals to write to (but not read) the laboratory results section of their 
record. Or they could provide public health authorities with access to their immunization 
history. All these patient functions can be easily incorporated with the EMR system that 
is based on HMOS APIs 



Integrated Nursing Module 

The Integrated Nursing Module (IND) in AST provides designated users an option to 
bring up multiple views from various perspectives such as Nursing Station-wise view, 
Doctor-Specialty-wise view, and Ward-wise-view. HMOS system, armed by its 
sophisticated privilege control system, ensures that such viewing privileges and 
associated functionality are accessible only by pre-authorized users. 

The IND module also provides HIS users a facility to designate a patient's clinical status 
to one of the following: 'Under IP Care', 'Marked for Discharge' etc. INS also furnishes 
a financial status entitled 'Send for Billing', which is a status-in-transition between 
clinical and financial status. These status transitions are processed under a strictly 
controlled rule base. IND provides facility to order material, drugs and services for 
patients. The bed transfer is efficiently tracked and will only be possible when all the 
orders are cleared and once the transfer is done the nursing station he previously occupied 
can do no order. 
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The IND application can be made available using the APIs provided by the Patient Care 
Management (PCM) module in the DST tier These APIs follow user-configurable rule- 
base. For instance, when a clinical status change needs to be processed, the PCM module 
calls on the services of 'View Helper' module within the FST tier to display the 
customized data corresponding for each view offered in the INS application. 

BIOMETRIC TECHNOLOGY FOR SECURE ACCESS 

A fingerprint offers a reliable and inexpensive means of authenticating an individual's 
identity; one far more secure than personal identification numbers (PINs) or passwords, 
which are subject to being compromised or forgotten. By linking the user directly to the 
transaction process through their fingerprint, proof is given that the authorized user is 
indeed present - not just someone who happens to know a short string of numbers or 
letters. This unique capability has been engineered into the HIS Biometric 
Authenticator, a complete, embeddable fingerprint identification system that can be 
inserted into a variety of access devices requiring user authentication. It performs all 
sensor, processor and decision-making functions within the module, greatly simplifying 
the incorporation of biometric recognition into small, mass-produced products such as 
smart cards. 

The Technology 

It employs a third generation capacitive array sensor chip that detects and captures small 
variations in finger surface capacitance and creates a three-dimensional electrical image 
of the fingerprint's unique pattern. To enroll a user in the Biometric Authenticator 
fingerprint identification system, one or more fingerprints of the authorized person must 
first be registered. This is accomplished in conjunction with an external enrollment 
station that activates and controls the process. First the user places his/her fingertip on the 
Biometric Authenticator module's sensor. It detects and captures the small variations in 
finger surface-capacitance and creates a three-dimensional electrical image of the 
fingerprint's unique papillary pattern. These signals are verified and then programmed 
under the control of the enrollment station into protected memory on the module. Upon 
completion of the enrollment process the module is "locked" and subsequent placement 
of any finger on the sensor triggers the verification process. This involves comparing the 
previously stored "registered" template with the fingerprint image using a special 
programmed algorithm. In the case of a fingerprint-enabled smartcard, if the result 
matches, the person holding the card (not just someone who happens to know the PIN) is 
verified as its authorized user. 
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Drug Interactions and Drug-Diet Interactions 



Adverse Drug Reactions (ADR) and drug allergies can cause serious threat to the life of 
patients. Identification of drugs that are known to cause ADRs can avoid prescription of 
drugs that may cause an allergic reaction in patients. This intelligence has been built into 
the Ordercom sub system of HIS so that the drug ordering process will automatically go 
through a screening process that checks whether the prescribed drug can cause negative 
side effects to the patient . Additionally, if cross-sensitivities of drugs that are 
pharmacologically or chemically related to the patient's primary allergens 
are found then the system will raise proper alerts. This is achieved through maintaining 
the patient's drug and clinical history and by the usage of the drug information data store 
provided by the HMOS Foundation Services Tier. The doctor also has the provision to go 
through the specific allergens that are known to the patient so that he can 
avoid prescribing drugs that can generate adverse effects with the patients. 

Dietary consistency is the key to maintaining a sustained, stable response during illness. 
Certain food items should be avoided for the proper functioning of some drug items. 

Scenario 1 : Legacy Systems 

A typical case study i.e. the patient dietary can be taken for explaining how the 
rule based health care information system helps in the better functionality of the entire 
process. If we consider the case of legacy systems where there is no tracking of 
concurrent information, it will make the process a mess, which can result in the major 
functional failure in the entire workflow and some times lead to inefficient patient care. 
In legacy systems there is no way to keep the information about the interaction between 
drugs and diet... Here all the process should work according to manual instructions, i.e. 
the some way the doctor himself or the nursing assistant should inform the dietary system 
about the permissible food details. Most of the time the decision taking here is not based 
on medical history of the patient or any knowledge base. There is no way by which the 
nursing assistant will immediately able to know what diet will fit to the current 
prescription and this can be ended up in supplying contradictory diet to a patient. So most 
of the times, lack of right information at the right time leads to unhealthy condition of the 
Patients. 

Scenario 2: HIS on HMOS 

This type of severe mistakes can be avoided in a rule based health care 
management system, which will be having all information about diet and the drug 
discrepancies. It also supplied with a set of functional rules, which can be used to quickly 
get the details from a knowledge base of the diet that should be supplied to the patient if 
his/her prescription includes a particular kind of medicine. The rules can be edited and 
supplied on time and the entire workflow will be changing according to the rule. This 
case is seemingly small but functionally hard on which the rule can be applied and rule is 
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effective in all such cases where there should take some decisions based up on some 
predefined criteria. 

This type of severe mistakes can be avoided in a rule based health care 
management system, which will be having all information about diet and the drug 
discrepancies. So in HIS as soon as the doctor prescribes the medicine a message 
composed of a list of permissible food items is published to the dietary system. The 
message is formed on the basis of predefined rules that are taken from the knowledge 
base for drug-food, drug-allergy, medical records and medical history for that patient. 
It is also supplied with a set of functional rules, which can be used to quickly get the 
details from a knowledge base of the diet that should be supplied to the patient if his/her 
prescription includes a particular kind of medicine. The rules can be edited and supplied 
on time and the entire workflow will be changing according to the rule. This can be an 
assurance given to the patient by the health care organization that within their system 
patient care is done as much as possible. 

Telemedicine and Integrated Video conferencing 

The domain service DICOM API and PACS facility enables the HMOS to act as a 
Service Class Provider so that all the clients connected with the HMOS application are 
enriched by the images. If a satellite pinging facility to the remote machines in another 
hospital, it is easy to integrate and retrieve the remote images to the PACS server of 
HMOS. 

Here the HMOS Domain Service Tier APIs does the handshaking for establishing the 
communication. After getting connection it can either query for an image or send an 
image through the network. The two machines, the local and remote, work as if they are 
in the same local area network. 

Quality of Service (QoS) 

HMOS is geared to pursue a simple yet organized approach to facilitate monitoring and 
control of health care business processes, in an efficient and cost-effective manner. 
Given the multi-dimensional nature in usage of products like HMOS, encompassing a 
wide range of functional domains, different QoS parameters are of interest, relevant to 
the user's perspective. Design of HMOS incorporates measures to guarantee a minimum 
level of QoS across all functional domains. QoS issues addressed within HMOS include: 

Functional Domain Measure of Performance 

User Interface/ human-factors based screen access/control 

Screen Navigation 

Context sensitive help 
Context sensitive error tracking/ 
Automatic error report generation 



multiple simultaneous 



Connectivity latency 
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HMOS users 



Guaranteed bandwidth 

Minimum transaction response time 

High Availability/low down-time 

Self-alert/correction of illegal field values screen by 

Screen 



Financial Performance' 



Return on Investment 
Accuracy and validated 



Asset Management 



Technical Performance 



Error-control/fault-tolerant 



Software Upgrades 



Non-disruptive/N S A 



The clinical data is integrated, secured and authenticated in accordance with the HIPAA 
compliant rules. Not only that the HMOS also provides an environment where those 
application which can go par with the HIPAA rule only be run on top of HMOS. This 
provides integration at the different level of the application and providing a standardized 
way of developing applications, which can run using HMOS as a platform. 

Horizontal and Vertical Extensibility of HMOS 

As newer standards emerge, they too can be incorporated into these tiers, thus 
ensuring horizontal expandability. This technology enables users to choose the c best of 
breed' products from different suppliers, and to optimize the price/performance ratio and 
quality of their information systems. Such a federation strategy allows users to make the 
best use of existing products and to replace or add components in accordance with their 
needs. 

HMOS provide plug and play architecture i.e. it is adaptable to change. Consider the 
case where a new protocol or a new standard is introduced in the field of health care. 
Since HMOS is horizontally expandable it is easy to plug the new service without 
affecting the core structure or the top-level applications. 

Both FST and DST tiers of HMOS are horizontally extensible. Newer services can be 
added to either of these tiers. For example to ensure that all applications written on 
HMOS support a new health care standard, the new standard can added as a Service in 
DST. By virtue of this, all HMOS applications are ensured compliancy to this standard. 
Vertical extensibility of HMOS means that health care applications may be developed 
above an existing set of applications in the AST. 

HMOS provides a common base and technology to build health care and hospital 
information systems locally in accordance with the specific needs of users. Handling of 
objects, invoking of services and therefore providing adequate interfaces are the 
objectives of middleware services of HMOS. It enables communication and co-operation 
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of application systems from different vendors on different platforms and with different 
application environments. In some hospitals legacy systems need to be preserved to 
protect past investments and to guarantee continuity of operations. This is made possible 
by the utilization of HMOS services which allows easy migration from existing solutions 
towards an open, distributed information system at moderate costs. 

The openness and modularity, and resulting flexibility of HMOS based systems facilitate 
easy adaptation to organization changes, both at short and long term, and allow effective 
use of technologies for business processes. In this respect the middleware-based open, 
architectural framework could be used as the change agent. Moreover, through open, 
standardized interfaces of HMOS services, health care organizations can realize even 
more savings downstream due to lower cost, interoperable solutions. 

By integrating the management of all the low level technical tasks in to a HMOS, we are 
achieving the same benefits as a systems programmer achieves from low-level operating 
systems like Windows or Unix. The functional modules of FST and DST together 
provide the essential services needed to build and manage an enterprise level Hospital 
Information System. HMOS provides FST and DST tiers of services and a set of services 
and tools in Application Service Tier (AST) that makes writing extensible and 
customizable applications is easy. HMOS effectively manages the resources for the 
efficient functioning of modules in the Application Services Tier and controls the 
interaction between the functional entities by scheduling of the core services. 

It will be apparent to the skilled artisan that the system of the invention described above 
in several embodiments is much more broadly applicable than to the narrow field of 
health care services. The examples of health care services are an important application, 
but serve as examples only. The characteristics of the invention can be applied in any 
area of human endeavor where distributed tasks must be planned and scheduled, and 
existing data must be sought and applied. Such areas include information management of 
all sorts, manufacturing systems, design systems for both hardware and software, and 
much more. 

Further it will be apparent to the skilled artisan that there are a variety of ways that the 
functionality described maight be implemented within the spirit and scope of the 
invention. There may be more or fewer modules, for example, and it is notoriously well 
known that different programmers may provide the same or similar functionality with 
very different code in different order. For these and other reasons the invention should be 
accorded the scope of the claims that follow. 



